Fonts are used by computers for on-screen displays and by printers for hard-copy printout. There are many different kinds of fonts available today. A "font" is a set of characters of the same typeface (e.g., Times New Roman, Arial, and Courier), style (e.g., italics), stroke weight (e.g., bold), and size (e.g., 12 point). More generally, a font defines how a set of characters appears when displayed or printed.
A font is commonly defined by a set of mathematical rules and glyph information contained in a font file. The rules define how a computer monitor or printer converts data into pixel data that is specific to turning on and off the appropriate dots, or pixels, to form the glyphs. A "glyph" is an exact shape of a character form. For instance, in a cursive (handwritten) font, the character represented by a lowercase "r" is rendered as one of two possible glyphs, depending on what character precedes it in the text.
To provide better quality glyphs, the amount of data contained in a font file continues to increase. As an example, a single font file for a Latin alphabet might consume 60 Kbytes of memory. For a Japanese character set, a single font file might be 15 to 17 Mbytes.
As the size of the font file grows, it is less convenient to supply the entire font for each application or usage of the font. For example, when a user downloads a Web page from the Internet, there is often no need for an entire font to accompany the Web page for rendering the small amount of textual content expressed on the page. Rather than downloading the entire font file (which might be large), a subset of the font file is downloaded. The subsetted font contains enough rules and glyph information to present the characters contained in the Web page.
The practice of font subsetting is well-known. A fairly recent problem that affects font subsetting concerns security. In particular, fonts that are passed over networks, and particularly public networks such as the Internet, face several security risks. One risk is that a party will copy the font file and reproduce it without permission, or make minor alterations, and then republish the font file for use in situations not intended by the font designer. This is particularly troubling for fonts protected by intellectual property. Font designers often license fonts with express conditions of when a font can, or cannot, be transported with a document or application. An unscrupulous party might attempt to tamper with the font file to change these conditions so that the font appears to legally grant permission to transfer the file in a manner not intended by the designer.
Another problem is that a font file, like other data files and code, might be infected with a virus. Still another problem is that an imposter might publish a font file of inferior quality, or one that is tainted, under the name of a reputable font designer. For these problems, it would be beneficial if the recipient of a font file could authenticate the source of the font file, and determine whether the font file has been tampered with since leaving the source.
To address these problems, font designers or publishers can digitally sign their font files by treating the file as a single stream of bytes. This technique is called a "flat file" approach. A recipient of a file can use the digital signature to verify that the font file was created by the designer and has not been subsequently altered. Unfortunately, the digital signature applies only to the original stream of bytes, and so when a font is subsetted, the signature is of no use for the subsetted font. By definition, the subsetting process necessarily converts the font file to a subsetted font file, and the digital signature is no longer valid for the subsetted font file.
One solution to the subsetting problem is to create, sign, and publish every possible subset of a font file. This solution is impractical because the number of subsets that are possible for a font is large.
Another solution is for the designer to predetermine a few common subsets, such as the most likely script/language ranges, and include signatures for each subsetted version of the font. The multiple signatures could then be stored in the font file. This technique is limited, however, in that the designer could not begin to anticipate all of the subsetting combinations that a content producer might desire. Moreover, the content producer might be unduly restricted to applying only the predetermined subsetted files.
Another possible solution is to establish a font server which, when a subset of a font is requested by a user, creates and signs the subsetted font on-the-fly and then issues the font to the user. In this scenario, the font servers would belong to font creators and would have access to private signing capabilities associated with the font creators, so that the font servers could create new signatures on-the-fly. With this technique, however, a tremendous investment in infrastructure is required. Additionally, this approach would potentially expose the signer's private key. It also requires content publishers to contact a font vendor every time a different subset is needed, which can be quite burdensome.
Accordingly, there is a need to develop a technique other than a flat file approach for subsetting a font in a manner that enables a recipient to verify the authenticity of the subsetted font.